Business Analyst Community & Resources | Modern Analyst

If you were to group software requirements into levels, how might you group them?

MostafaElbarbary — Fri, 18 Apr 2008 19:34:00 GMT

The Business Analysis Body of Knowledge® (BABOK®) defines the following levels of requirements:

“Business Requirements are higher-level statements of the goals, objectives, or needs of the enterprise. They describe things such as the reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure success.
Stakeholder Requirements are statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how the stakeholder will interact with the solution. Stakeholder Requirements serve as a bridge between Business Requirements and the various classes of Solution Requirements.
Solution Requirements define the characteristics of a solution that meets the Business Requirements and Stakeholder Requirements. They are frequently divided, particularly when the requirements describe a software solution, into:
- Functional Requirements describe the behavior and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations – a specific system action or response.
- Non-Functional Requirements capture conditions that do not directly relate to the behavior of functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the system must have. They are also known as quality or supplementary requirements.
Implementation Requirementsdescribe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to the desire future state, but that will not be needed once the transition is complete” (Business Analysis Body of Knowledge® 2008).

BABOK and Business Analysis Body of Knowledge are registered trademarks owned by the International Institute of Business Analysis.

According to Ian Sommerville (1997) the software requirements types are:

User requirements: are written for customer in natural language and simplified diagrams which describe system features and services.
System requirements: are written as a contract between client and the contractor, and it is a structured document setting out detailed descriptions of the system services.
Software specification: A detailed software description which can serve as a basis for a design or implementation and are written for developers.

According to Karl E. Wiegers (2003) the software requirements levels or types are:

Business requirements: are written to represent the high level objectives and goal of the organization or stakeholders who want to build the system.
User requirements: describe the user goal which the user desires from the new system.
Functional requirements: specify the software functionality that the developers must build into the product to enable users to accomplish their tasks.

According to Suzanne Robertson and James Robertson (2006) the software requirements level or types are:

High-level requirements: are written to specify the business the product is intended to support
Business requirements: are written in a technologically neutral manner they specify what the product is to do for the work, not which technology is used to do it.
Product's technological requirements: are written by designer who adds those requirements needed to make the product work in its technological environment.

According to the Rational Unified Process the software requirements level or types are:

Stakeholder requests: are written in User language to capture all user requests.
Features: are written to capture all feature of the system under development.
Use cases: are written to capture functional requirements.
Supplementary requirements: are written to capture Non-functional requirements (Leffingwell 1999).

References:

Business Analysis Body of Knowledge (version 2.0). 2008. International Institute of Business Analysis. pp 8-9.

Leffingwell, Dean & Don Widrig. 1999. Managing Software Requirements (First Edition). Addison Wesley.

Robertson, James and Suzanne Robertson. 2006. Mastering the Requirements Process (Second Edition). Addison-Wesley Professional.

Sawyer, Pete and Ian Sommerville. 1997. Requirements Engineering: A Good Practice Guide (First Edition). Wiley.

Wiegers, Karl. 2003. Software Requirements (Second Edition). Microsoft Press.

What type of information should be documented in a use case specification?

MostafaElbarbary — Fri, 18 Apr 2008 19:30:00 GMT

While use cases are included in the Object Management Group’s UML® Specification, the UML specification does not define the form or content that should be included in a use case specification. For this reason, there is no single standard. Precisely what information should be included varies based the source you reference. Nevertheless, most methodologies and authors show a significant degree of agreement regarding the information that should be included in a use case specification.

The most popular use case specification template is probably the Rational Unified Process Template. It includes the following information.

Use Case Name
Brief Description
Actors
Triggers
Flow of Events
- Basic Flow
- Alternative Flows
Special Requirements
Pre-Conditions
Post-Conditions
Extension Points

In his book, Writing Effective Use Cases, Alistair Cockburn (2001) shows several examples of use case specifications, most of which include the following information:

Context of Use
Scope
Level
Primary Actor
Stakerholders and Interests
Preconditions
Minimal Guarantees
Success Guarantees
Trigger
Main Success Scenario
Extensions
Technology and Data Variations list
Special Requirements

Additionally, Scott Ambler (2004) offers a simplified template in The Object Primer that includes the following information:

Name
Identifier
Description
Goal
Pre-conditions
Post-conditions
Basic course of action
Alternative course of action

References:

Cockburn, Alistair. 2001. Writing Effective Use Cases. Addison-Wesley Professional.

Ambler, Scott W. 2004 The Object Primer: Agile Model-Driven Development with UML 2.0 (Third Edition). Cambridge University Press.

What is difference between an Essential Use Case and a System Use case?

MostafaElbarbary — Fri, 18 Apr 2008 19:21:00 GMT

“An essential use case is a structured narrative, expressed in

the language of the application domain and of users,

comprising a simplified, generalized, abstract, technology-free

and implementation independent description of one

task or interaction that is complete, meaningful, and well-defined

from the point of view of users in some role or roles

in relation to a system and that embodies the purpose or

intentions underlying the interaction” (Constantine and Lockwood (1999).

Said another way, an essential use case describes the interaction between the user and the system at a high level of abstraction. The goal of an essential use case is to convey the most important aspects of the user-system interaction by focusing on the user’s intent (avoiding any reference to an assumed UI design or technological implementation) and on the observable result of the system (without specifying the internal steps the system takes to achieve the result). Since an essential use case describes only the most important information it represents a single success scenario.

In contrast, a system use case describes the interaction between the user and system in a more detailed way than and essential use case. While still trying to avoid referencing any UI specific features when possible, usually certain aspects of the technology to be used can be assumed. For instance, when writing a system use case, it is usually known whether the user will interact with a telephonic system, an internet application, or a piece of manufacturing equipment. Similarly, system use cases provide more detailed description of the steps that the system will perform to fulfill the need of the user. In order to avoid committing to a specific UI design, this detail should still be expressed in logical terms. However, it paints a clearer picture of the requirements that the GUI must satisfy.

References:

Constantine, Larry L., and Lucy A. D. Lockwood. 1999. Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. Addison-Wesley Professional.

What are some of the formats used for writing use cases?

MostafaElbarbary — Fri, 18 Apr 2008 19:06:00 GMT

To ensure that we understand what is meant by the term format, consider the following. Most authors and practitioners do not clearly differentiate between style and level of detail when defining use case writing formats. Style refers to the structure of the use case or how the use case information is presented. Level of detail refers to the state that a use case is in as it evolves from nothing more than a use case name to a fully described or fully dressed use case. Most authors and practitioners generically use the term format to describe some combination of these two concepts.